In the life cycle of software development, a “bug” means a program malfunction caused by programming or logic errors. One small bug might bring unacceptable loss in many special industries such as military, medical and financial industry. It's because of the potential risk of great lost that all commercial application programs are tested and debugged as completely as possible before release.
However, the rising complexity of software system brings more and more bugs that can not be re-produced or just occur occasionally. For these bugs, developers can not know when they will occur. They may occur on some special systems or they may occur after a long time, such as one hour or even several days, since the program is started. Even more, some of them might disappear if the target program is being controlled by one debugger. In this invention, the item Runtime Bugs will be used to represent the above program deficiencies.
Traditional debuggers could do little on Runtime Bugs. When one Runtime Bug occurs, if one debugger is started now to debug that program, it may be too late in that the context of bugged program is unavailable. JIT (Just-In-Time) debugging is proposed to address the above problem. JIT debugging is a technique by which the debugger could be invoked automatically when Runtime bugs occur. It has become an integral part of modern debugging. So far, some methods or systems have been designed to provide the JIT debugging. Among them, JIT debugging through exception hook and JIT debugging through OS-specific exception are two widely adopted methods.
The method JIT debugging through exception hook is put forwarded by the U.S. Pat. No. 5,526,485 incorporated herein by reference. It was to address the problem that the Windows 3.1 operating system is not able to load and run a debugging program in response to a program error. FIG. 1 shows a whole process of the method of JIT debugging through exception hook. In this method, with the help from an API library named TOOLHELP, one monitor program, which resides in memory, registers exception hooks with operating system. In response to an exception, the operating system will call the callback function, e.g. exception processing function formerly registered by monitor program. Then, the just-in-time monitor program will ask users whether they want to debug the target program or not. If the user indicates that debugging is desired, the callback function of the monitor will start a debugger configured in advance for the user to do interactive debugging. There are some problems in this method:
(1) This method introduces an additional JIT debugging monitor, which must be started before the target program is launched and it will always reside in system memory. Although the system resources consumed by the monitor might not be too many, it is undesirable in many cases because the presence of the JIT debugging monitor in system memory and the related consumption of resources might have an effect on the target program, precluding effective debugging;
(2) The method is not process-specific. It's oriented to all processes, which makes users bored by many notifications from other processes not cared by users at all;
(3) The method is of little flexible customizability. After the monitor is loaded into the memory, the registered exception hook functions have to keep unchanged. If they want to do some changes according to different requirements at different stages of one JIT debugging session, users have to modify the monitor program and restart it again. However, such actions will break up the entirety of one JIT debugging session.
(4) The method is based on an API library, named TOOLHELP, of the Windows. Therefore, it's possible for a number of different application programs to register the same type of exception hook functions. When one exception occurs, the operating system calls the registered exception hook functions in sequence until one hook function returns one special value to indicate the exception resolved. Thus, one exception interrupt, which should be originally captured by the JIT debugging monitor, might be handled by registered hook functions of other programs, which means users will lose chance of JIT debugging.
(5) This method is unable to provide JIT debugging for Runtime Bugs brought by incorrectly handled software interrupts
Another method, JIT debugging through OS-specific built-in mechanism, is being widely taken by Microsoft Windows® operating system, such as Windows® 2000/XP/NT. The method is based on the built-in mechanism of Microsoft Windows®. Refer to http://msdn2.microsoft.com/en-us/library/5h4b7a6.aspx. The Microsoft Windows® operating system provides a mechanism referred to as “Exception handling”, in which when one exception occurs, such as segment fault, the running program generating the exception will be notified by the kernel and given the opportunity of self-correcting, e.g. “First Chance Exception handling”. If the application program is unable to handle or correct the exception, the operating system will attempt to handle it in a procedure called “Last Chance exception handling” or “Second Chance Exception handling”. If it fails too, the operating system has a built-in mechanism for starting a utility program which can “connect” to the target program and extract information about the program in its faulty state before it is terminated.
The method of JIT debugging through OS-specific built-in mechanism utilizes above mechanism. Microsoft Windows uses one key in Windows registry to store the path of a debug loader program, such as the vsjit.exe provided by Microsoft Visual Studio. When one exception fails to be handled during the Last Chance exception handling, the kernel will extract the value of the registry key and launches the program. Then the program will notify users and check whether one debugger should be launched.
Although the method of JIT debugging through OS-specific built-in mechanism is better than the method of JIT debugging through exception hook in some ways, for example, no exception hook functions need to be registered, no monitor program resides in memory and there is no need to start additional program before launching target programs, the method of JIT debugging through exception hook can just only capture fatal exceptions. However, during debugging process, users care not only these fatal exceptions but also some common exceptions, which are handled in First and Last Chance Exception handling. If object program gets one unexpected exception at some certain circumstances, the method will not help. Furthermore, the method is also unable to provide debugging for Runtime Bugs brought by incorrectly handled software interrupts.